dart_skills_lint v0.4 prep: native binary preview track#158
Conversation
- New tag-triggered release workflow builds dart_skills_lint as a standalone native binary for macOS arm64/x64 and Linux x64/arm64 via `dart compile exe`, packages each as a tarball with SHA256, and cuts a GitHub Release with release notes extracted from CHANGELOG.md. - New install.sh detects OS/arch, downloads the matching tarball, verifies SHA256, and installs to INSTALL_DIR (default /usr/local/bin with sudo fallback). REPO/VERSION/INSTALL_DIR are env-configurable so the script survives the impending dart_skills_lint repo move with a single default-value edit. - Pub.dev install paths (`dart pub global activate` and dev_dependency) are unchanged; binaries are a parallel channel. - macOS binaries in this preview are unsigned. Homebrew formula is deferred until the new home repo is settled to avoid forcing early adopters through a re-tap on migration.
- actions/upload-artifact: v4 → v7 (was the Node 20 deprecation warning source from the first fork test) - actions/download-artifact: v4 → v8 - softprops/action-gh-release: v2 → v3 All three were on Node 20, which GitHub forces to Node 24 on 2026-06-16. Each matrix job uploads with a unique artifact name, so v5+'s duplicate-name restriction is non-issue. download-artifact v8's new error-on-hash-mismatch default is a security upgrade.
Lead with install.sh as the recommended path; add a direct-curl variant for environments that don't pipe scripts to bash. Keep the pub.dev paths (dev_dependency and `dart pub global activate`) unchanged under a "Dart developers" section. Documents the macOS Gatekeeper workaround for unsigned preview binaries, a brief note that Homebrew is coming after the imminent repo migration, and the pinning syntax to opt into the preview track. Bumps the stable caret range example from ^0.2.0 to ^0.3.0.
There was a problem hiding this comment.
Code Review
This pull request introduces a native binary distribution channel for the dart_skills_lint tool (version 0.4.0-dev.1), adding a new installation script (install.sh), updating the README and CHANGELOG, and bumping the package version. The review feedback highlights two important improvements for the installation script: first, handling macOS Gatekeeper blocks gracefully during the post-install verification step so that the troubleshooting instructions are actually displayed to the user; second, making the SHA256 checksum verification more robust by stripping potential binary mode indicators (like *) from the checksum file fields.
| "$install_path" --help >/dev/null 2>&1 \ | ||
| || err "installed binary at ${install_path} failed to launch." |
There was a problem hiding this comment.
If the preview binary is blocked by macOS Gatekeeper, running "$install_path" --help will fail and trigger the || err ... block, causing the script to exit immediately. As a result, the user will never see the Gatekeeper troubleshooting note printed at the end of the script. Handling the verification failure gracefully on macOS and printing the troubleshooting instructions directly on failure ensures a much better user experience.
| "$install_path" --help >/dev/null 2>&1 \ | |
| || err "installed binary at ${install_path} failed to launch." | |
| if ! "$install_path" --help >/dev/null 2>&1; then | |
| if [ "$os" = "macos" ]; then | |
| echo "install.sh: error: installed binary at ${install_path} failed to launch." >&2 | |
| echo "This is likely because the preview binary is not yet code-signed and is blocked by macOS Gatekeeper." >&2 | |
| echo "To fix this, run:" >&2 | |
| echo " xattr -d com.apple.quarantine \"${install_path}\"" >&2 | |
| exit 1 | |
| else | |
| err "installed binary at ${install_path} failed to launch." | |
| fi | |
| fi |
There was a problem hiding this comment.
Fixed in 76ff632. The Gatekeeper note now prints before the --help smoke test so users always see the xattr -d com.apple.quarantine instruction even when the launch is blocked. On macOS specifically, a failed --help is downgraded from a hard error to an informational message since the install itself succeeded — the launch will work once quarantine is cleared. Non-macOS still hard-errs on launch failure (catches real issues like glibc mismatch).
| || err "could not download ${sums_url}" | ||
|
|
||
| # --- Verify SHA256 ---------------------------------------------------------- | ||
| expected_sha="$(awk -v fname="$archive" '$2 == fname { print $1; exit }' "${tmpdir}/SHA256SUMS")" |
There was a problem hiding this comment.
The current awk pattern matching $2 == fname can fail if the SHA256SUMS file contains a binary mode indicator prefix (like *) before the filename (e.g., da39a3ee... *dart_skills_lint-linux-x64.tar.gz). Stripping any leading * from the second field makes the verification more robust across different platforms and tools.
| expected_sha="$(awk -v fname="$archive" '$2 == fname { print $1; exit }' "${tmpdir}/SHA256SUMS")" | |
| expected_sha="$(awk -v fname="$archive" '{ sub(/^\\*/, "", $2); if ($2 == fname) { print $1; exit } }' "${tmpdir}/SHA256SUMS")" |
There was a problem hiding this comment.
Fixed in 76ff632. The awk now strips any leading * from field 2 before the filename comparison, so SHA256SUMS files in either text or binary mode (sha256sum -b) work. Verified locally against both forms — input abc123 file and def456 *file both correctly extract the hash.
- install.sh:118 (high): print the macOS Gatekeeper note BEFORE the --help launch check so users see the xattr workaround even when Gatekeeper blocks the binary. On macOS, downgrade the --help failure from a hard err to an informational message since the install itself succeeded; the launch will work once quarantine is cleared. Non-macOS still hard-errs on launch failure. - install.sh:80 (medium): strip leading '*' from SHA256SUMS field 2 before comparison so binary-mode hash files (sha256sum -b output) work as well as text-mode.
| case "$(uname -m)" in | ||
| arm64|aarch64) arch="arm64" ;; | ||
| x86_64|amd64) arch="x64" ;; | ||
| *) err "unsupported architecture '$(uname -m)'. Supported: arm64, aarch64, x86_64, amd64." ;; |
There was a problem hiding this comment.
is aarch64 the correct thing here?
There was a problem hiding this comment.
They are the same thing. I believe aarch64 is what linux will report, arm64 is what mac will report.
|
|
||
| # --- Detect platform --------------------------------------------------------- | ||
| case "$(uname -s)" in | ||
| Darwin) os="macos" ;; |
There was a problem hiding this comment.
For each of these cases pull the supported list from the checked list.
| will not auto-pick this up; pin explicitly (`dart_skills_lint: 0.4.0-dev.1`) | ||
| to try the preview. | ||
|
|
||
| ### Distribution |
There was a problem hiding this comment.
Here and below is way to long follow the structure of the change logs below and keep it focused on user facing changes/benefits.
|
|
||
| On macOS, replace `sha256sum -c -` with `shasum -a 256 -c -`. | ||
|
|
||
| ### 3. Dart developers — pub.dev |
There was a problem hiding this comment.
Make the dart developers section first.
- install.sh: collapse three hand-rolled "Supported: ..." messages behind one SUPPORTED_TARGETS constant, so the error text and the final platform check share a source of truth. Error text now lists normalized targets (macos-arm64, macos-x64, linux-x64, linux-arm64) instead of raw uname variants. - CHANGELOG.md: shrink the 0.4.0-dev.1 entry to match the 0.3.1 style — flat user-facing bullets, no internal workflow detail or Homebrew roadmap. - README.md: reorder the Installation section so the pub.dev path (existing Dart audience) comes first, followed by install.sh and the direct-download path for the no-Dart preview audience.
| env: | ||
| VERSION: ${{ steps.meta.outputs.version }} | ||
|
|
||
| - name: Create GitHub Release |
There was a problem hiding this comment.
For a v0.5:
- We can mark releases as immutable. Github will make the sha256 for us. Binaries cannot change.
- It means we upload all binaries in the release step like this.
- name: Create Immutable GitHub Release
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh release create ${{ github.ref_name }} ./all-assets/* \
--title "Release ${{ github.ref_name }}" \
--generate-notes
Adds a v0.4 with the goal of supporting users that may not have dart installed.
Specifically there is a:
.github/workflows/dart_skills_lint_release.yaml) buildsdart_skills_lintas a standalone native binary formacos-arm64,macos-x64,linux-x64, andlinux-arm64viadart compile exe, packages each as a SHA256-verified tarball, and cuts a GitHub Release whose notes are extracted fromCHANGELOG.md.tool/dart_skills_lint/scripts/install.shdetects OS/arch, downloads the matching tarball, verifies its SHA256 against the release'sSHA256SUMS, and installs toINSTALL_DIR(default/usr/local/bin, with sudo fallback).REPO/VERSION/INSTALL_DIRare env-configurable so a future repo migration costs one default-value edit.0.4.0-dev.1; CHANGELOG and README updated.What is not done but was considered:
dart_skills_lintsettles into its dedicated repo.xattr -d com.apple.quarantineworkaround for the preview window. This will need to come after launchcal approval.Test plan
dart_skills_lintworkflow stays green on this PR (matrix tests on ubuntu/macos/windows + coverage + pana ≥160).dart_skills_lint-v0.4.0-dev.1from main; confirm the new release workflow publishes a GitHub Release with all four tarballs +SHA256SUMS+install.sh.